One of the key issues associated with mobility management of recent mobile terminals is a network-based mobility support protocol. Most terminals are equipped with an existing mobility management protocol such as MIP (mobile IP), accordingly, the terminal is required to be modified. Such drawback is one of the major reasons why the existing mobility management protocol has not been widely applied in the meantime.
On the contrary, the network-based mobility support protocol has the advantage of not asking for any modification of a mobile terminal because the mobility management of the terminal is handled by the network side.
Meanwhile, the IETF (Internet Engineering Task Force), which is currently an international standard organization for developing and promoting Internet-related protocol standards, has established the NETLMM (Network-based Localized Mobility Management) WG to standardize a network-based mobility support protocol. For example, PMIP6 that is adopted and now under development by the NETLMM WG is a protocol expanded from the existing MIP6 protocol to conform to the specifications of a network-based mobility support protocol.
Hereinafter, the structure of a conventional PMIP6 domain will be described with reference to FIG. 1.
FIG. 1 shows the structure of a conventional PMIP6 domain. As shown in FIG. 1, the PMIP6 domain structure is largely constituted by a mobile node 100, MAGs (Mobility Access Gateways) 102aa, 102bb, and 102 cc, an LMA (Local Mobility Anchor) 104, and a profile server 106.
The LMA 104 is connected to the Internet network, and maintains location information of which MAG in the PMIP6 domain the mobile node 100 currently belongs to, and packet forwarding information.
The MAGs 102a, 102b, and 102c are the ones that practically perform the mobility management on behalf of the mobile node 100. More specifically, the MAGs 102a, 102b, and 102c serve to detect whether the mobile node 100 is connected to or departed from a subnet under their own management, and provide the LMA 104 with the current location information of the mobile node 100 and the packet forwarding information.
The profile server 106 manages profile information of the mobile node 100, and offers the profile information of the mobile node 100 at a request for the profile information from the MAGs 102a, 102b, and 102c. 
A description of how a mobile node is connected to a PMIP6 domain with the structure above and of how the mobile node moves within the domain will follow with reference to FIG. 2 and FIG. 3.
FIG. 2 illustrates a connection procedure of the mobile node to the PMIP6 domain shown in FIG. 1.
First of all, when the mobile node 100 is connected to the MAG 102a in step S200, the MAG 102a requests the profile server 106 to provide profile information of the mobile node 100 (i.e., mobile terminal), and receives the profile information from the profile server 106 in step S202. The profile information contains prefix information of the mobile node 100 (including home prefix thereof).
When the connection of the mobile node 100 to the MAG 102a is detected, the MAG 102a sends a BU (Binding Update) message to the LMA 104 in step S204. The BU message contains the prefix information of the mobile node 100 provided from the profile server 106.
The LMA 104 that receives the BU message sets up forwarding information for the mobile node 100 by using the prefix information contained in the BU message, and then sends a BA (Binding Acknowledge) message to the MAG 102a in step S206.
Next, the MAG 102a that receives the BA message establishes a tunnel using itself and the LMA 104 as both end-points, and then sets up forwarding information of the mobile terminal based on the prefix information in step S208.
FIG. 3 illustrates how a mobile node moves within the PMIP6 domain depicted in FIG. 1.
First, when the mobile node 100 connected to the MAG 102a moves to a coverage area of the MAG 102b in step S300, steps S200 through S208 shown in FIG. 2 are performed to establish a tunnel between the LMA 104 and the MAG 102b, and forwarding information of the mobile node 100 is then set up based on the prefix information in step S302.
When the movement of the mobile node 100 from the MAG 102a to the MAG 102b has been completed, the LMA 104 sends a message for de-registration of a home prefix of the mobile node 100 to the MAG 102a. 
Through this procedure, the mobility management for the mobile node within the PMIP6 domain is performed. Since the MAGs 102a, 102b, and 102c associated with one LMA 104 in the PMIP6 domain advertise the same home prefix to the mobile node 100, the movement among them is regarded transparent to the mobile node as if it moved on a single link.
As explained so far, the conventional PMIP6 provides mobility without requiring any modification on the mobile terminal (i.e. mobile node) side. One of operational features of the PMIP6 is that when a mobile terminal is connected to a specific MAG of a PMIP6 domain, the MAG is connected to the profile server to obtain profile information of the mobile terminal. This profile contains a home prefix of the mobile terminal, which is used for the MAG to identify a mobile terminal packet that will be transmitted to the LMA.
However, such a home prefix is merely the prefix information of the mobile terminal (mobile node)'s own address. Therefore, in case where a mobile node is a mobile router and a PMIP6 domain is used as a home network for the mobile router, there is no method to process a mobile network prefix including the address of a node that belongs to the mobile network managed by the mobile router.